Such traffic processing is performed by means of devices known as service functions, and referred to below as SF functions. Among the SF functions commonly used, there are to be found, by way of example:                quality of service functions, such as marking and classifying traffic or conditioning and scheduling traffic;        security functions, such as encrypting traffic, installing and actuating filters defined using access control lists maintained by certain routers of the IP network, and also IPv4 or IPv6 firewalls;        network address translation (NAT) functions such as NAT64 functions (mechanisms enabling IPv6 clients to communicate with IPv4 servers);        probe functions such as deep packet inspection (DPI), e.g. for parental control purposes;        functions for personalizing or optimizing Internet connections, such as “TCP Optimizer”;        functions for optimizing video content; or indeed        functions for inserting information into headers of the hypertext transfer protocol (HTTP).        
SF functions may be hosted by all kinds of equipment, e.g. a router, a server, or a switch. Furthermore, a single piece of equipment may host one or more SF functions. In the context of the present invention, a node of an IP network is said to be “associated” with an SF function when that SF function is hosted on the node or is accessible via the node: furthermore, a node associated with at least one SF function is referred to below as an “SF node”.
Installing a value-added service that benefits from a differentiated traffic transport policy generally requires a plurality of SF functions to be combined (which may indeed be hosted on one or more nodes of the network), possibly in an order that is characteristic of the flow direction of the traffic (e.g. from the Internet to a terminal or from a terminal to the Internet), in order to form functional chains. The term “service function chain” (SFC) designates an ordered sequence of SF functions. In other words, the chain of SF functions gives a list of SF functions that are to be used for processing a data stream in a manner that is characteristic of said service, and gives the order in which the functions are to be used sequentially for processing the stream.
For example, transmission control protocol (TCP) traffic sent by clients who do not have an IPv6 protocol stack may imply chaining a TCP optimization function, an IPv6 firewall function, and a NAT64 function in order to enable those clients to access IPv4 content that is available on the Internet; and the processing of TCP traffic going to such IPv6 clients may involve chaining an IPv4 firewall function and a NAP64 function in order to enable such clients to receive said IPv4 content that is available on the Internet. Another example is that of a virtual private network (VPN) service that makes use of transport and routing functions combined with quality of service and security functions distributed in various elements making up the IP network that supports the VPN, or in elements that are connected to the support network, such as a firewall.
Explicit indicator means (e.g. marking conveyed by each packet forming part of a given stream) are then necessary in order to inform to the equipment hosting the individual SF functions about the chains of which they form a part in order to process the stream(s) associated with the chain. Each piece of equipment hosting at least one individual SF function forming part of an SFC then refers to that explicit indication in order to decide how to process each packet forming part of said stream.
Service function chaining techniques are recent. The state of the art shows that the first development of this service function chaining technique relies on approaches that are monolithic and involve only one manufacturer.
Thus, the article by M. Boucadair, C. Jacquenet, R. Parker, D. Lopez, J. Guichard, and C. Pignataro, entitled “Service Function Chaining: Framework & Architecture draft-boucadair-sfc-framework-00” (available at the following address http://tools.ietf.org/html/draft-boucadair-sfc-framework-00), describes a procedure for creating a chain of service functions. It also describes a generic service function chaining architecture and the functional entities needed for installing such an architecture. That article in particular gives the responsibility for constructing SFCs to entities that it calls policy decision points (PDPs).
In this respect, it should be recalled that the resource allocation protocol (RAP) working group of the Internet engineering task force (IETF) has defined, in a document RFC 2753, a functional architecture that is specific to the management of networks implementing one or more policies (such as traffic transport and routing policies, or quality of service policies, or indeed security policies such as encrypting the transmitted data). In particular, that architecture defines devices referred to as PDPs, which in the context of service function chaining are responsible for taking decisions about the structuring of service function chains relying on a set of SF functions, and are responsible for notifying these decisions to the nodes of the network that are involved in deploying and operating said service. In particular, the PDP is responsible for taking decisions making it possible to apply various differentiated traffic processing policies by one or more nodes of the network, and that leads to ad hoc functions being configured in the network nodes in question. PDP devices may be hosted by way of example in a server, a gateway, or a router. In the context of the present invention, the term “PDP node” is used to designate a node hosting a PDP device.
In said article by Boucadair et al., the PDP communicates with the network elements hosting the SF functions and the stream classification functions, to give them instructions relating to installing differentiated traffic processing, characterized by a variety of service function chains used for processing all of the traffic streams transported in the network, as a function of their respective natures. The article specifies in particular that the PDP needs to have knowledge of the list of service functions that are active in the network and also of their locations; nevertheless, that article does not specify how the PDP can acquire such knowledge.
Conventionally, the list of SF service functions is configured in static manner. The configuration procedure consists in storing in a file that is local to the PDP all of the information relating to SF functions (complete configuration) or merely a list of SF function identifiers (partial configuration). With partial configuration, the PDP needs to make use of a domain name system (DNS) service for resolving identifiers in order to recover other useful information (e.g. one or more IPv4 or IPv6 addresses).
Unfortunately, that conventional configuration suffers from several drawbacks.
Firstly, it is difficult to maintain a service database that is constantly up to date and that matches the dynamics of the network services that are to be produced. This is a particularly severe constraint when the list of service functions to be activated for processing a given traffic stream is large and the combinatorics of the SF functions making up such a list is often complex.
Secondly, the DNS service cannot give the PDP dynamic information about major events (that might affect the decision-making process of the PDP), such as the introduction of new SF functions or SF functions additional to the existing SF functions but of the same kind, or the configuration of a new redundancy group or “cluster” (e.g. a server cluster) or a given service function so as to optimize the robustness of the service function chains, or indeed the capacity to indicate that a service function is unavailable.
Thirdly, by its very nature, static configuration is incompatible with the principle of automating the service production process. Static configuration is also incompatible with operational practices that consist in dedicating a team of network administrators to each SF function, and in separating the teams in charge of planned maintenance of the network and the equipment making it up, from the teams in charge of operating certain segments of the network, since in this context such operating practices will tend to put into question the overall consistency of management operations (configuring and operating SF functions) at the scale of the network, with the risk of degrading the quality level associated with supplying a given network service.